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(57) Abstract: Configuring software for a target 
comprises preparing a command fi|e (509) which 
specifies a subset of components (545, 546) selected 
from a group of components, and parameters (546) 
for tuning at least some of the selected subset of 
components. The command file is written using 
a single object-oriented programming language, 
capable of managing tree structures of objects, 
preferably an XML type language, having a 
Document Type Definition enabling it to work as 
a programming language. An image file (548) is 
prepared from the command file, to be loaded (550) 
on the target. 
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Preparation of a software configuration using an XML type 
5 programming language 

This invention relates to computer technology. 

The operating system (OS) named ChorusOS (SUN MICROSYSTEMS, 
10 ST QUENTIN EN YVELINES, France) is a realtime embedded OS, 
flexible as to the hosting hardware, T?his implies that it has 
to be installed and configured on a variety of computer plat- 
forms. ~ r - ^ 

15 For being installed on a particular machine ("target"), 
ChorusOS has to be configured, i.e. prepared depending upon 
the target characteristics, and the application software to 
be supported. After the preparation, the size of the program 
code may range from 10 kilobytes for a portable machine to 

20 several megabytes for a telecom switch, for example. 

Existing versions of ChorusOS use a palette of different 
programming tools to enable the selection of the desired 
elements of ChorusOS for a particular target, and for 

25 adapting the same to that target, as needed. More precisely, 
different specific languages were used for "tuning" the 
configuration, for defining features thereof, and also for 
defining the memory layout thereof. Generally, discussions 
are made in this application in the context of ChorusOS, but 

30 the present invention is widely applicable across ohter 
systems. 

This invention intends to improve the preparation of a 
software configuration for a given machine or target. 

35 

One object of this invention is to provide a single program- 
ming language common for substantially all steps of the 
preparation of a software configuration. 
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Another object of this invention is to provide such a single 
programing language in a form which is simple, standard and 
flexible m use, preferably as an implementation of the 
extended Markup Language (XML). 

A further object of this invention is to enable the construc- 
tion of a hierarchically organized tree of data representing 
the software configuration. 

Still another object of this invention /is to enable the 
preparation of a software configuration to be made on a 
dedicated machine, with the help of a Graphic User Interface 

(GUI ) . 

There is proposed a method of configuring software for a 
target, comprising: 

preparing commands which specify: 

al. a subset of components selected from a group of 
components , 

a2. parameters for tuning a least some of the selected 
components in said subset, and 
b. preparing an image file from the command file. 

The above method is of particular interest in providing 
25 cross-platform compatibility, in accordance with the 
invention. 



a. 



According to an aspect of this invention, step a. comprises 
writing the commands in a command file using a single object- 
oriented programming language, capable of managing tree 
structures of objects. Preferably, the command file is an XML 
file, and the single programming language is specified using 
an XML document type definition, having at least one nestable 
element predefined to receive an attribute pointing on a 
file, other features of the XML document type definition will 
be defined hereinafter. 

Advantageously, the command file and image file are prepared 
on a host system separate from the target. Then, preferably, 
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step a) further comprises: a3. loading the subset of compo- 
nents on the target. For target operation, the method further 
comprises the step c. of loading the image file in the 
target. 

Minimally, the image file includes at least an operating 
system kernel. It may also include an operational file 
system. Preferably, the image file also defines parameters, 

actions, and memory layout of the software. 

* 
/ 

According to another aspect of this invention, step b. 
comprises: 

bl. preparing a make file from said command file, and 
b2. building said image file using said make file. 

15 

The invention also encompasses a computer program product, 
comprising the group of components of step al., the code of 
the XML document type definition in claim 2, and the code for 
implementing step b, or portions of these codes usable in a 
20 commercially available software environment. The computer 
program product may further comprise code for implementing 
step a3, and/or code for implementing step c. 



Still in another aspect of this invention, there is provided 
25 a system for configuring software for a target, comprising a 
host having 

a. A group of components; 

b. Software for preparing a command file which speci- 
fies 

30 bl . a subset of components selected from the group 

of components, 
b2. parameters for tuning at least some of the 

selected subset of components, 
b3. loading of the subset of components on the 
35 target, 

said software using a single object-oriented 
programming language, capable of managing tree 
structures of objects, 

c. Software for preparing an image file, and 
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d. A link for loading the image file and the selected 
subset of components in the target. 

The above system is subject to additional features similar to 
5 those enunciated on the basis of the method. 

This invention also covers a co^and file fro, which an image 
fying " n be Prepared ' th * co^nand file speci- 

a- a subset of components selected from a group of 
components At ^ 

b. parameters for tuning at least some of the selected 

subset of components, 
c loading of the subset of components on the target. 

This invention further covers a computer program product 

ZHTl 3 "T™^ ~"<-. -ing a e— L file 
from which an image file for a target can be prepared the 
command file specifying ' 

a. a subset of components selected from a group of 
components, 

b. parameters for tuning at least some of the selected 
subset of components, 

c loading of the subset of components on the target. 

This invention still further covers the combination of the 
command file with the corresponding image file. 

Other characteristics and advantages of the invention will 
appear in the light of the detaiied description below and the 
associated drawings in which: 

which' 'th- " " 9Sneral diS9ram ° £ tW COmpUt « S ""°"= - 
which this invention is applicable ; 

- rig. 2 shows the memory main components in host station 100 

°I rig. 1; 
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- Fig. 3 shows software modules involved in configuring a 
target station; 

- Fig. 4 shows how an ECML file may be submitted to syntactic 
5 and semantic analysis; 

- Fig. 5 is a flow chart showing the main steps of the 
configuration process, as implemented before this invention; 

10 - Fig. 6 is a flow chart showing the ^main steps of the 
configuration process as implemented in accordance with this 
invention; and 

- Fig. 7 is a flow chart showing step 540 of Fig. 6 in more 
15 detail. 

Additionally, features of the new language used in this 
invention (ECML) are defined in Exhibits I and II; Exhibit 
III shows a portion of an ECML configuration file. 

20 

Making reference to a language also imposes certain conven- 
tions in notation. In the detailed description: 

- the quote sign M is used as character string delimiter 
wherever deemed necessary for clarity (e.g. "TITLE" hereinaf- 

25 ter), 

- where the language name is an abbreviation of the current 
name, square brackets frame the rest of the current name 
(e.g. ENUM[eration] hereinafter). 

30 Existing versions of ChorusOS are defined in "Sun Embedded 
Workshop, ChorusOS Technical Overview", CS/TR-96-119, SUN 
MICROELECTRONICS, Palo Alto, California 94303, USA. 

An instance of the ChorusOS operating system always includes 
35 the core executive component of ChorusOS. Optional components 
in the operating system provide additional services. The 
following list of such services is not meant to be complete, 
as other services may be provided: 

- Actor Management 
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- Scheduling 

- Memory Management 

- Proxy Management 

- Inter-thread communication 
5 - Time Management 

- Inter-process communication 

- Local Access Points (LAP) 

- Debugging 

- Initialization and command interpreter (CJTNIT) 
10 - File System Options ' . / 

- I/O Management 

- Networking " r " 

- Administration. 

- Graphic user interface (GUI). 

These optional components can be added to, or removed from, 
an instance of the ChorusOS operating system, in this way, 
the operating system can be very finely tuned to meet the 
requirements of a given application or environment. 
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25 



Each API function in the ChorusOS operating system is 
contained in one or more of the configurable components. As 
long as at least one of these components is configured into 
a given instance of the operating system, the function is 
available to be called. However, certain pure library 
functions are independent of any specific component and are 
always available. 



30 



35 



In Fig. 1, target T is the computer intended to receive 
ChorusOS. The target board 800 has a processor 801, elementa- 
ry firmware 802, a memory 805 and peripheral devices 820, 
which may belong to a custom designed peripheral board. The 
configuration process concerning the target is performed from 
a host or installing computer H . The host board 100 has a 
processor 101, e.g. a SPARC (a product and trademark of SUN 
MICROSYSTEMS ) , an operating systen, 102, e.g. Solaris (a 
product and trademark of SUN MICROSYSTEMS), a memory 105 
(encompassing both working memory and mass memory, i.e. hard 
disk, where appropriate), and may further include the usual 
display no, mouse (or other pointer) 111 and keyboard 112. 



WO 01/44934 PCT/1B99/02003 

7 

An appropriate link 900 is made between the host and the . 
target , under control of firmware commands on the target 
side. 

5 As shown in Fig. 2, a portion of memory 105 (RAM or DISK) 
contains software configuration data, i.e. various software 
modules serving as tools for the configuration process, or as 
constituents of the software to be installed. 

10 Building and configurating such a system requires the 
selection and configuration of the kernel ' and operating 
system generic portions, and also of a processor family 
dependent portion. Additionally (Fig. 3), it includes the 
selection and configuration of components defining: 

15 - binary modules corresponding to a variety of supported 
processors and processor architectures, 

- Board Support Packages (BSP), supplied by the applicant 
company for a variety of different custom boards, 

- pieces of code (so-called "drivers") for the board 800, and 
20 - application software as desired. 

Thus, configuring the OS for a particular machine means: 

- selecting between a light or full version of the OS, with 
a very large number of intermediate situations, 

25 - ensuring coherence of the OS before it may be launched by 
the OS user. 

This configuration and build process encompasses providing a 
variety of information ranging from the selection of OS 
30 modules to the definition of the memory layout of the 
deployed system on the target. 

Concretely, the primary result of the configuration process 
is an "image file" (also termed "archive"). When installed on 
35 the target machine (e.g. in epROM or flash memory), the image 
file is capable (after suitable initialization, like re- 
booting) to have it operate consistently in the desired 
hardware and software configuration. 
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In the present invention, the following new capabilities are 
sought: 

- The applicant company provides Board Support Packages (BSP) 
for a number of peripheral boards available from various 

5 independent hardware vendors. It has been found desirable to 
supply the BSPs in a form which comprises binary code 
dedicated to the board itself, and source code for the 
platform dependent portions of the BSP, e.g. Application 
Program Interfaces or APIs. '..» 

10 - distinguishing between programming API,is (e.g. in Posix), 
and configuration APIs. Configuration is here' intended to be 
understood in a very generic fashion, i.e. all the informa- 
tion that is not purely programming API and that is required 
to build the target system and adapt it to a specific 

15 hardware and to a specific usage. 

Accordingly, in the present invention, configuration will 
cover: 

- feature configuration, i.e. the appropriate subset of 
20 components required in the system, e.g. scheduling classes, 

memory management support, 

- tunable configuration, e.g. specific system values, number 
of threads in the kernel, size of communication buffers, 

- memory layout of the various components of the system, 
25 - driver properties, 

- third party application configuration. 

In accordance with an aspect of this invention, a single 
configuration programming language has been designed for 
30 processing such folders as objects. Preferably, this single 
configuration programming language is based on the XML 
language standard, and named "Embedded Component Markup 
Language" (ECML) . 

35 XML (for extended Markup Language) is a recent hypertext 
metalanguage standard, specified by the XML working group. 
For understanding the XML aspects of this invention, refe- 
rence is made to the XML recommendations, available on the 
INTERNET at http://www.w3.org/TR/REC-xml, or to the booklet 
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"XML Pocket Reference", Robert eck«stpt» 

October 1999. ECKSTEIN, O'REILLY, U.S.A, 

The basic markup principle of XML is « 
5 - let " TITLE" hp - , follows: 

- in thl S Ct6d Character "ring, 
in the corresponding XML document «w 

TLE> " and "< /TI TLE>" is an ..e,^:' iS b ~ ■<«- 

- a Document Type Definition (n T m ■ 

element may contain m« , . determines what that 

in - . y contain (including other ne^ e H <o 

10 its attributes. * nes ; ted elements), and 

I 

i 

-m the mark : "^'r; " «-•«» «• a nd 

fs to trigger actions referred 
document itself, o „ ^ei erred to the XML 

itself, e.g. print "TITLE" and "author- 
font sizes. author m different 

By contrast, the newly proposed ecmt 1= 

^ a programing Cg.^, ^ iS "> 
the actions being triggered bv the Pr ° blemS ' 

to the XML document itself « Pr ° 9ram ^ * 6Xternal 

,nent itself. However, as i + ,,*n w 

considerably simplify *k be Seen ' ECML 

-cess of Choruses based - — 

The DTD for Ecra , ls glve „ in 

"XXXXX" is a kevworH o <!XXXXX" and ">», where 

<a Keyword, e.g. "ELEMENT" *nr? + 

W1 - » ith - « .ore other Z e " 3 
are case-sensitive. The dtd provides a formal H r^" 10 "* 
the events with < ! ELEMENT .... > and ™t ^ 
with <UTTLIST >, „„ their at «ib"tes, 

the data element" » rel ationship among 

elements. An <• ENTITY * 
parameter entitv f nr • . clause builds a 

e— . are^osT ^ZVZ Z ^ 
h been ^ J; The 

f«rs, for purpose of description. i„ Ej!hiblt I: 



20 



WO 01/44934 PCT7IB99/02003 

11 

- sections Al and A2 prepare entities for the DTD, defining 
what a "container" and a "content" will be. 

- sections B uses the "container .mdl" and "content .mdl" 
entities to define the element "configuration" and its 

5 attributes, while defining further entity "conf ig .mdl" . 

- section C uses the "container .mdl" and "content .mdl" 
entities to define a further entity "folder .mdl" , and 
prepares elements "folder", and "folderRef". 

- section D prepares the element "description". 

10 - section E defines the entity "type. mdl"; while sections El 
through E6 prepares the elements corresponding to various 
types of variables: "bool", . "int"/. "string", "enum" , 
"struct", "list". 

section F defines the entities "boolExpr .mdl" and 

15 "expr.mdl", and prepares the elements corresponding to the 
boolean expressions "and", "or", "not", to the boolean/arith- 
metic expressions "equal", "notEqual", and to "ifdef". 

- sections Gl through G5 prepare the elements/attributes for 
giving a value to a variable, as a constant "true", "false", 

20 "const", or by reference to another object "var", "ref", 
"vstring" . 

- section H defines the entity "field. mdl", and prepares the 
element "field" . 

- section I prepares the element "condition". 

25 - section J defines the entity "definition .mdl " , and prepares 
the element "definition", and the elements "feature" and 
"tunable", which are directly related to software configu- 
ration. 

- section K defines the entity "setting. mdl" , and prepares 
30 the element "setting", for assignment of a value to a 

variable. 

- sections L and M prepare the elements "constraint" and 
"parameter" . 

- section N prepares the elements "action" and "application". 
35 - section 0 prepares the element "typeDef", for definable 

types of variables. 

- section P prepares the elements "using", "value", and 
"default" . 
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eXa, " PleS ° £ Pr09 " m "cements using 

ECML. in the beginning: 

- II. 1.1 and ii. 1.2 respectively define a boolean variable 

rZbC n 61 "' t0 trU6 ' 3n intSger V - iable v.- 

riable2", having the value 1024. 

- II. 1.3 shows how "my_variablel" may be later set to false 

- II. 1.4 shows how "my_variable4" may be created with the 
value of "my^variab]^" . 

ECML allows the definition of actions/ Each action is 
characterized by: , „ 

• its "name", a string of characters, 1 

• its "application", a string of characters, 

• its "parameter", a reference to a defined variable. 

Example II. 2 defines an action "my_action", associated to the 
application "my_application" , which will be called with the 
variable "my_ variable" . 

The -action- is the entry point for calling application 
plngms, while binding these tools to descriptions, when 
parsing a configuration ECML file, application plugins are 
called with associated parameters. A description can be 
optionally associated with an action. The expression is 
evaluated if there is no condition associated with the 
constraint or if the condition associated with the constraint 
evaluates to true. Application processing is tool specific. 
The application- element defines the plugin that should be 
called The parameter associated with the application can be 
defined using a local definition or a reference to a defined 
variable. 

Example H.3.1 shows how a new type "my_type- is defined. 
This type is a structure that contains two fields "myfieldl- 

° ,T ,, i , nte9er and ■"SLfi.ld*. of type boolean. Example 
II. 3. 2 illustrates the definition of a variable of type 
"my_type". yp 
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In example II. 4, if the variable "my_condition" evaluates to 
true, the variable "my_variable" will be defined; if the 
variable "my_condition" evaluates to false, the definition 
container will not be processed. Generally, ECML allows 
5 association of a condition with an element; then, the element 
is processed if and only if the condition evaluates to true. 

In order to check consistency between variables, ECML uses 
"constraints", each characterized by ^ boolean expression. In 
10 example II. 5, if the variable "my condition" evaluates to 

true, the constraint is verified. If the variable "my condi- 

- «• ... r ... 

tion" evaluates to false the constraint evaluates to false. 

Example II. 6 shows an AND logical function with variables 
15 "my_conditionl " and "my_condition2 " . 

ECML provides support to organize the information described 
through "folder" and "folderRef" elements in a hierarchical 
manner. The "folder" element is the container element that 

20 provides encapsulation of other elements. A "folder" is 
characterized by its "name", a string of characters. Example 
II. 7.1 defines a folder "my_folder", containing two folders 
"my_subf older 1 " and "my_subf older2 " . The "folderRef" element 
of II. 7. 2 is the container element that is used to create a 

25 reference to another file. The referenced file "filename" is 
embedded for processing in the body of the folder "my_folder n 
at the location of the reference. Relative paths are assumed 
to be relative to the directory containing the file being 
parsed. 

30 

The above reflects the fact that, when using XML, any 
language element must be then be defined, with its own 
markups, in contrast with other programming languages. This 
results some complexity, since e.g. example II. 1. needs four 
35 lines, in lieu of a program statement often written as 
follows : 

my_variable = TRUE 
Despite that complexity, it has been found possible to 
elaborate an XML based programming language, at least for use 
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in configuring software. Furthermore, this approach has the 
advantage of providing the program as a fully structured 
text, m which automatic tools (programs) may later easily 
and safely fetch any information they require. 

As shown in Fig. 4, the ECML file may be submitted to a 
syntactic analyser 211, using the corresponding DTD 201. if 
desired (for non-developers,, it may be submitted to a 
semantic analyser 212, using a library 202 containing the 
semantic rules to be applied. / 

It results from the above description 1 that ECML provides, 
inter alia, support for: 

- defining a variable (integer) with a mechanism (or "trig- 
ger") to check its value with respect to a minimum and a 
maximum; 

- defining constraints between variables, using boolean 
calculus ; 

- associating the definition of a variable to conditions 
M expressed by other variables; 

- later updating of a variable having already be defined; 

- managing lists, in the form of an object model- 

- organizing the configuration in a hierarchical manner in 
multiple files; 

25 - organizing the naming space of variables (an XML feature). 

Together, these two last mentioned organizing tools permit to 
cope with the diversity of managed information and the number 
of component providers. 

30 

Thus, according to a basic concept of this invention, all the 
necessary information or data for the OS configuration is 
arranged as a tree-structured set of "folders", such that any 
folder has a parent folder, starting from a head folder. 
35 Through "folderRef", a folder may be connected to an indepen- 
dent file. Certain folder files may be modified. This enables 
the folders to includes files of different origins, which 
have to be organized for proper operation. Thus, the appli- 
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cant felt the need for an adequate structured sequential 
programming language. 

An example of a much simplified ECML file will now be 
5 described, with reference to Exhibit III: 

- Lines 4-6 are the usual XML header, defining the XML 
version and the applicable DTD. 

- Then, line 8 creates a folder "Kernel Configuration", 
having a "f olderRef " . * ; 

10 - Lines 11-30 create a [sub ] folder "Cjore Executive", in 
which the feature "H0T_RE START" is disabled, the feature 
"USER_MODE" is enabled, and the "feature "ROUND_ROBIN" is 
disabled. 

- Lines 32-60 create a [sub ] folder "Kernel core tunables" , 
15 in which the tunable "chorusSiteld" is set to integer 0, the 

tunable "kern. exec. maxCpuNumber " is set to integer 1, the 
tunable "kern. exec. maxActor Number" is set to integer 64, and 
the tunable "kern. exec. maxThreadNumber" is set to integer 
128. 

20 - Lines 62-80 creates a [sub ] folder "Virtual Address 
Space". It will be processsed only if the variable "VIR- 
TUAL_ADDRESS_SPACE" is true. If so, a feature "ON_DEMAND_PA- 
GING" is created, which will be processed only if the 
variables "VM_available" and "PRM_available" are both true. 

25 The feature "ON_DEMANDJP AGING" is set to false. 

The configuration process will now be described, using the 
terminology of ChorusOS. The discussion of ChorusOS is 
exemplary only, and the invention is not limited to ChorusOS. 

30 

Generally, configuring ChorusOS firstly comprises selecting 
components, using the boolean variables called FEATURES; this 
results into a LIST of components. 

35 The configuration process comprises three other levels of 
system configuration: 

a) Resources. For the list of selected components of FEATU- 
RES, it is possible to fix the amount of resources which are 
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to be managed. This uses variables, representing tasks, 
buffers, and other parameters for adapting the target system 
to its own desired configuration (for example a pager needs 
only a small number of internal OS processes or actors). Some 
of the variables (the "tunable") are preferably "tuned" to 
avoid spoiling resources which are of no use in the target as 
desired. Thus, it is also possible to set the value of those 
tunable variables, for example, the amount of memory reserved 
for network buffers. The TUNABLE variables are mostly integer 
and string variables, but may also be / defined using an 
ENUM[eration] type variable. The . TUNABLE may belong to the 
components themselves, or be various resource (e.g. memory) 
parameters. They usually are an integer having minimum and 
maximum values, e.g. to represent the network buffer size 
while avoiding meaningless configuration such as a negative 
value therefor. 

b) Boot Actors, it is possible to include additional actors 
in the memory image that is loaded at boot time. The list 
management, done in the form of an object model, simplifies 
significantly the description of a list and reduces the 
possibility of mistakes. Here, for example, including 
additional actors in the memory image uses list management: 
more information must be associated with each actor added 
into the image such as linking address, actor type, and so 
forth. This is a refinement of the target image building 
process done according to this invention. 

c) Environment. System-wide configuration parameters can be 
fixed by setting UNIX-like environment strings, which the 
operating system and actors retrieve when they are initiali- 
zed. For example, an IP address can be defined globally by 
setting LOCAL_INADDR to '192.33.15.18'. This implies allowing 
for definition and management of variables such as L0CAL_I- 
NADDR . m order to check the correctness of the configuration 
statically, these variables should be typed, possibly with 
definable types. 
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This is monitored by configuration tools, which take care of 
any hidden dependencies or possible incompatibilities. An 
element having its "visible" set to "no" serves that purpose. 

5 ECML enables to simply associate the definition of variables 
to conditions expressed by other variables. This is very 
useful, since a software configuration largely depends on 
itself: for example, the Ethernet driver should be tuned if 
and only if it has been selected. Thtis, a "driver_to_be_tu- 
10 ned" boolean variable may be defined from d "driver_selected" 
boolean condition. r 

t 

With the ability to define constraints between variables, 
using boolean calculus, it becomes possible to use a sophis- 
15 ticated rule-engine to check the validity of a configuration. 
This rule-engine implements boolean calculus on features, 
based on boolean expressions. This mechanism provides support 
for checking feature dependencies such as: "Ethernet driver 
is required by TCP/IP feature". 

20 

Fig. 6 shows diagrammatically the new configuration process, 
using ECML. Defining the configuration (500) is now simply 
writing an ECML file 509, described in further detail below. 
The checkings reduce to a single step 529, a part of which 

25 may be implemented in real time during the ECML file edition. 
The rest of the steps is similar, however with various 
significant changes, like the modular structure of the 
objects or folders being called or used by the make file, and 
the possibility for the make file execution to interact with 

30 the ECML file (not shown in Fig. 6). 

Preferably, a set of predefined configurations 508 ("profi- 
les") are provided. The configuration process is then 
decomposed in two steps: 
35 • selection of a predefined configuration. As seen hereinaf- 
ter, the configuration operator defines the desired configu- 
ration using an XML text editor, together with a command line 
tool and/or a graphical tool, for launching "actions" of the 
configuration producing system. The "actions" comprise: 
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- designating one or more folder object files or -OF 
and * ' 

- checking that the designated FOFs are coherent with 
previously designated FOFs and between themselves. 

witTthe" ^ S6leCted C ° n "™on, « desired, 

" T£L TTt? to restore the pradeflned values - 

Lnaoeld , associa « d tools provide a mechanism to 

manage modif ications made to the configuration . 

' ItrTo/V 1 " ECML " le " 5W ' i » -"ten under 

control of the operator ,00. preferably with the help of 
configuration assistant tools 528. ' 

The information accGssihio +^ 

not h» « ■ ° CeSSlble to the configuration operator may 

not be sufficient to this effect „j »v. 

in.,,,, „,,... effect, and the system may also 

include "hidden" information comprising: 
- a list of available objects, 

-a list of "tuning" tools defining how those of the objects 
which are "tunable" may be tuned. 

At least at the level of developers (e.g. for the predefined 
configurations,, the ECML file may be edited by us'n, a 
standard editor, that can be computed with XML specific 
modes (such as "emacs", a text editor of the GNU) . 

L h rs EC alut U dr y ^ diSPUyed thr ° U9h "andard b — 

sers, adapted to work with the XML language. Optionally, the 

browser may receive extensions to handle XML, in order to 

grllcal i 7 te inClUded ' enabli " 9 USe «* -"ting 
graphical tools functions. 

As an XML file, an ECML file may be processed or parsed using 

a software module na m ed "XML processor", enabling access to 
the data t and to ^^^^^ t 

process o a rth OT ^ " ^ ^ ^ «- 

further ac *"* «>• XML processor 

further acts as some Kind of program interpreter, for 
performing the desired steos cf *„t. 

steps of software configuration, in 



WO 01/44934 PCT/1B99/02003 

19 

the example being described here. Each such step may be 
executed like a command line (command line mode), or the 
steps may be piloted using a graphic user interface, i.e. 
graphical tools, mode targeted to end-users to configure the 
5 system. 

The basic processing of ECML files in command line mode is 
split in two phases: 

• parsing the ECML file, which in tujpn involves two proces- 
10 ses: / 

* XML parsing 

* semantic analysis 

* tool invocation. 

15 The semantic analysis may be made using an XML semantic 
analyser, taking into account the needs shown in the DTD. If 
desired, a syntactic analysis may be made using an XML 
syntactic analyser like JAVA XML sold by the applicant. 

20 The result of the processing is a list of defined variables. 
A simple interface is provided to browse this list of 
variables. This interface is used by the tools involved in 
obtaining configuration information. 

25 ECML integrates easily into a Java graphical tool, which is 
an additional key evolution to simplify the overall process 
of building the system, and more easily allows future 
evolution of configuration information. 

30 Fig. 7 shows on more detail how. the image file is built, by 
applying the make process 540 to the "make file" 535. 

Basically, the make file comprises individual steps of 
action. Each such step 541 fetches a particular software 
35 module (a file in the host) which is first compiled at 542, 
if not already available in binary form. 



After compilation, the modules then have to be linked at 54 4. 
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in the case 545 of a fixed (invariable) software module, the 
Unking step is direct. For the case 546 of a configurable 
software module, the linking step will access the ECML file 
509, as necessary to obtain the information defining the 
particular configuration parameters of the software module 
being linked. This uses the folder organization of the ECML 
file, and the value(s) in the " TUNABLE " object for the 
software module being processed. This is another advantage of 
ECML. y 

1' 

i 

When the image file is, finalized at, 548, step 549 preferably 
interacts with ECML file 509, essentially to update it with 
further information relating to the image file itself, 
including the future memory layout in the target (as it will 
be explained in more detail hereinafter). Thus, the ECML file 
contains not only what is necessary to build the make file, 
and then the image file, but also information as how the 
image file is in itself, and may be installed in the target 
memory. This is still another advantage of ECML, and is of 
interest for testing purposes, if required, step 549 also 
defines the additional components, to be loaded by the image 
file. 



Later, a test step 560 may also add debug-oriented 
information 561 into the ECML file, thus rendering it to be 
a complete representation of the whole configuration process, 
including the testing. 

in the example of ChorusOs, a module named MKIMAGE enables to 
make an image file for the target. The system image is the 
initial state of the target board's physical memory, it 
contains a set of files organized in one or more memory 
banks. When the target system is deployed, some of the system 
image memory banks are burnt into non-volatile physical 
memory. The rest can be downloaded from a local device or 
from the network by the initial loader. 

More precisely, in the example, the MKIMAGE command builds a 
binary file called "bootconf", and containing a data 
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structure also called Bootconf, which describes the system 
image contents and layout. MKIMAGE includes the bootconf 
binary file in one of the system image memory banks. When the 
target will be started, the initial loader will boot the OS, 
5 jumping to the entry point of bootconf binary. In fact, 
"bootconf" is a board-independent program that gets control 
from the board-specific initial loader and transfers control 
to the board-specific bootstrap program. The initial loader 
may pass a board-dependent parameter to the bootstrap. 
10 ,V - j 

Thus, MKIMAGE creates the system image as defined in the ECML 
configuration file. The configuration may specify a list of 
memory banks, and, for each particular bank, a symbolic name, 
a base address, and a size limit. Upon request from the 

15 configuration file, MKIMAGE may also organize at least some 
of the memory banks as a file system volume. The 
configuration file may also specify a list of files 
(components) to be included in the system image, and, for 
each particular file, the bank where the file will be stored. 

20 In addition, relocatable files may be processed; for such a 
file, the configuration may specify how the file may be 
relocated, when stored in a memory bank. 

Accordingly, the configuration file enables to closely 
25 describe and visualize the fine organization of the target. 



In other words, after the configuration has been entirely 
defined (509) and checked (529), a succession of processing 
modules ("tools") may be involved during the process of 
30 building an image file (530,540): 

- a first tool (546) extracts tunable information from the 
configuration ECML file and generates the appropriate code to 
implement the tunables; 

- a second tool (549) builds the appropriate object list, 
35 based on the list of components used in the system; 

- a third tool (548) builds the image file to be downloaded 
to the target, based on the image description. 
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It will be seen that the ECML file acts as a common infras- 
tructure between those tools. Each tool uses a subset of the 
information. Therefore, ECML additionally provides entry 
poants for tools. 

This invention also covers the proposed software code itself 
especially when made available on any appropriate computer- 
readable medium. The expression "computer-readable medium- 
includes a storage medium such as magrietic or optic, as well 
as a transmission medium such as a digital /or analog signal 
The software code basically includes the code for use in the 
configuration process itself, it may also include at least 
some of the group of software components to be installed. The 
invention also covers the code (image file) obtained as a 
result of the configuration process, both alone and in 
association with one or more corresponding XML files, with or 
without the corresponding DTD, which may obtained through 
different channels. 

The invention has particular interest in the context of 
configuring software and similar applications. However, the 
concepts used in building a programming language from XML 
have interest in themselves. Thus, these aspects are also 
covered, inter alia in the form of an XML processor, compri- 
sing: 

- a parser for acquiring at least a portion of an XML type 
file, and a corresponding document type definition, and 

- an analyser for identifying objects in said portion of said 
XML type file, said objects comprising variables, values, 
operations, conditions and commands. Other described features 
also intervene in enabling an XML type file with a DTD to be 
used as a program file. The DTD enabling this is also part of 
the invention, whether presented apart from the XML file, or 
at least partially incorporated therein. 
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Exhibit I - ECML DTD 

<!-- Al. Container --> 

< ! ENTITY % container. mdl 

'(description?,condition?,typeDef*, 
» (definition {feature | tunable)*, 

setting*, action*,constraint*)' > 

< !-- A2. Content --> 

< IENTITY % content. mdl '(folder J folderRef)*' > f; 



10 <!-- B. ChorusOS image config. --> - 

< ! ENTITY % config.mdl '%container.mdl;,%content.mdl;' > 

< ! ELEMENT configuration (%config.mdl;)> 

< IATTLIST configuration 

nam e CDATA ^REQUIRED > 

15 

< !-- C. Folder > 

< ! ENTITY % folder.mdl '%container.mdl;, %content.mdl;' > 

< .'ELEMENT folder (%folder.mdl;)> 

< IATTLIST folder 

20 nar "e CDATA ^REQUIRED 

visib, e (yes| no) IMPLIED 

configurable (yes | no) #IMPLIED > 

< ! ELEMENT folderRef EMPTY > 

< IATTLIST folderRef 

25 xml-link CDATA IMPLIED 

nref CDATA ^REQUIRED 

actuate (auto | user) ^IMPLIED 

visible (yes | no) ^IMPLIED > 

30 < !-- D. Elements description -- > 

< IELEMENT description (#PCDATA) > 



< !-- E. Type -- > 
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IMPLIED 
IMPLIED > 



< ! ENTITY % type.mdl 'bool j int j string | enum j struct | list j type' > 
< !- El. Boolean constant --> 

< ! ELEMENT bool EMPTY > 
< !-- E2. Integer constant. --> 

< ! ELEMENT int EMPTY > 

< IATTLIST int 

min CDATA 
max CDATA 
< !-- E3. String -- > / 

< IELEMENT string EMPTY >' " 

< IATTLIST string 

kind (filename ,'dirname) IMPLIED > 

< !-- E4. Enumeration > 

< "ELEMENT enum (const +) > 

< !-- E5. structures --> 

< 'ELEMENT struct (field+)> 

< .'ATTLIST struct 

CDATA 



key 

< •'-- E6. lists --> 
) < IATTLIST list 
ref-only 



(yes| no) 



IMPLIED > 



#IMPLIED> 



< !ELEMENT list (%type.mdl;)> 



< !- F. Expression - > 

< ! ENTITY % boolExpr.mdl 

"var ! true | false | and j or j not j equal | notEqual | ifdef | imply j onlyOne' > 
< ! ENTITY % expr.mdl ; ref | vstring j const | %boolExpr.mdl; ' > 

< .'ELEMENT and ((%boolExpr.mdl;)+) > 

< .'ELEMENT or ((%boolExpr.mdl;)+) > 

< .'ELEMENT not (%bool Expr.mdl;) > 

< .'ELEMENT equal ((%expr.mdl;), (%expr.mdl;))> 

< 'ELEMENT notEqual ((%expr.mdl;), (%expr.mdl;)) > 

< 'ELEMENT imply ((%booIExpr.mdl;), (%boolExpr.mdl;)) > 
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< ! ELEMENT onlyOne ((%boolExpr.mdl;)+)> 
< ! ELEMENT ifdef EMPTY > 

< IATTLIST ifdef 

name CDATA #REQUIRED> 

5 

< !- G. Values --> 

< !-- Gl. Boolean constants --> 

< [ELEMENT true EMPTY > V ■ 

<! ELEMENT false EMPTY > ' , 

10 <!-- G2. String, integer and enum constants --> 

< ! ELEMENT const (#PCDATA) > 

< !-- G3. Value is given by the var (can be any type) -- > 

< IATTLIST var 

name CDATA ^REQUIRED > 

15 < ! ELEMENT var (using)? > 

< !-- G4. Reference to a variable --> 

< ! ELEMENT ref EMPTY > 

< IATTLIST ref 

name CDATA IMPLIED > 

20 < !-- G5. String value. Can reference variables value (enclosed by {name}) --> 

< .'ELEMENT vstring (#PCDATA)> 



< !- H. Structures fields -- > 

< ! ENTITY % field.mdl 'description?,(%type.mdl;),(%expr.mdl;)?' > 
25 < ! ELEMENT field (%field.mdl;) > 

< IATTLIST field 

name CDATA #REQUIRED 

optional (yes | no) IMPLIED 

ref-only (yes } no) IMPLIED > 

30 

< !-- 1. Condition --> 

< I ELEMENT condition (%boolExpr.mdl;)> 
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< !-- J. Declaration of variables --> 

< ! ENTITY % definition. mdl 'description? s condition?,(%type.mdl;) ; default?, 

(%expr.mdl; lvalue*)?' > 
< ! ELEMENT definition ( Redefinition. mdl ;)> 
5 < IATTLIST definition 

name CDATA ^REQUIRED 

configurable (yes J no) IMPLIED 
visible (yes j no) >, #IMpLIED 

global (yes! no) IMPLIED > 

10 < .'ELEMENT feature (%defirrition.mdl;)> 

< IATTLIST feature 

name CDATA ^REQUIRED > 

< IELEMENT tunable (%definition.mdl;) > 

< IATTLIST tunable 

name CDATA #REQUIRED> 

< !-- K. Variable assignment - > 

< IELEMENT setting (description?,condition?,(%expr.mdl; j value*)) > 

< IATTLIST setting 

name CDATA #REQUIRED 

visible (yes| no) IMPLIED > 



15 



20 



< !- L. Constraint definition « > 

< .'ELEMENT constraint (description?, (%boolExpr.mdl;)): 
25 < IATTLIST constraint 



30 



name CDATA 

< !-- M. Parameter definition --> 

<. 'ELEMENT parameter (%expr.mdl;)> 



<!-- N. Action --> 
< IELEMENT action 

(description?..condition?,appljcation,(definition j %expr.mdl;)) : 



#REQUIRED > 
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< IATTLIST action 

name CDATA 
visible (yes | no) 

< ! ELEMENT application (#PCDATA)> 
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^REQUIRED 
IMPLIED > 



10 



< !-- O. Definition of types -- > 

< ! ELEMENT typeDef (description?, (%type.mdl;))> 

< IATTLIST typeDef t"' 

name CDATA 

< ! ELEMENT type EMPTY > " ~" 

< IATTLIST type 

name CDATA 
ref-only (yes | no) 



^REQUIRED > 



#REQU1RED 
IMPLIED > 



15 < !— P. Member and list access. --> 

< IATTLIST using 

field CDATA 
index CDATA 

< .'ELEMENT using (using)? > 

20 < .'ELEMENT value (%expr.mdl; j value +) > 

< IATTLIST value 

field CDATA 
index CDATA 

< I ELEMENT default (const j true j false) > 



^IMPLIED 
IMPLIED > 



IMPLIED 
#IMPLIED> 
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Exhibit U - ECML Fundamentals - Examples 



IU.l 

< definition name='my variable' > 
<bool/> 

<true /> 
10 < /definition > 

II. 1.2 

< definition name= 'my_variable2' > 

< int / > 

1 5 < const > 1 024 < /const > ' " ' 
< /definition > 

II. 1.3 

< setting name = 'my variable l'> 
20 <bool /> 

< false /> 

< /setting > 

II. 1.4 

25 < definition name = 'my variable4'> 
< int /> 

<var name = 'my_variable2' /> 

< /definition > 

30 H.2 

< action name='my_action'> 

< application > my_application < /application > 
<var name='my_variable' /> 

< /action > 

35 

II.3.1 

< typeDef name = 'myjype ' > 

< struct > 

4 0 < field name = 'mv fieldl ' > 
< int /> 
< /field > 

< field name = 'my field2' > 
<bool/> 

4 5 < /field > 

< /struct > 

< /typeDef > 
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11.3.2 

< definition name= 'my_variable' > 
<type name='my_type' /> 

< value field = 'my_fieldl'> 1024 < /value > . 

5 < value field = 'my_field2' > < true / > < /value > 

< /definition > 



II.4 

10 < definition name='my_variable' > 

< condition > <var name = 'my_condition' /> < /condition > 
<int /> 

< const > 1 024 < /const > : > 
< /definition > , ,. f 

15 

II.5 

< constrain! name=*my_consrrainr > 
<var name='my_condition' /> 

20 < /constraint > 



II. 6 Boolean Arithmetic 
<and> 

25 <var name = 'my_conditionr /> 
<var name='my_condition2' /> 
< /and > 



30 II.7.1 

< folder name = 'my_f older' > 

< definition > . . . < /definition > 

< folder name = 'my_subfolderr > 
35 ... 

< /folder > 

< folder name='my_subfolder2'> 

< /folder > 
40 < /folder > 



II.7.2 

< folder name = 'my_f older' > 
45 ... 

<folderRef href = 'filename' /> 

< /folder > 
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] Exhibit III - Example of a simple ECML file 
2 

3 

4 <?xml version = '1.0'? > 

6 sOS^a^^ f ° ,der PUBL1C '" //SUn Micros y s, ^s//DTD ChorusOS/ZEN' 'Choru- 
7 

8 < folder name= 'Kernel Configuration^ 

9 < foIderRef href = 'kern f .xml ' / > 
10 

11 < folder name= 'Core Executive' > 

12 ;V 

13 < feature name ='HOT_RESTART'> / 

14 < description > Hot restart support < /description > 

15 <bool /> * r " 

16 < false /> 

17 < /feature > 
18 

19 < feature name ='USER_MODE'> 

20 < description > User mode execution support < /description > 

21 <bool/> 

22 < default > <true /> < /default > 

23 < true / > 

24 < /feature > 
25 

26 < feature name= 'ROUND ROBIN' > 

27 < description > POSIX round-robin scheduling class < /description > 

-^o < bOOl / > - r 

29 < false /> 

30 < /feature > 
31 

32 < folder name = 'Kernel core tunables' > 
33 

34 < tunable name='chorusSiteId'> 

35 < description > Unique Chorus Site Identifier 

37 dfictoo"^ 10 ^ ^ 3U, ° matically P rovided 10 ,he kernel ^ the board-spe- 

38 ^ NI ^ G: wjw set, must be set with different values within every boot image 
^ dedicated to different target boards < /description > 

40 <int/> y 

41 < const >0< /const > 

42 < /tunable > 
43 

44 < tunable name = 'kern. exec.maxCpuNumber' > 

45 < description > Maximum number of processors < /description > 

47 <const>l</const> 

48 < /tunable > 
49 
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50 < tunable name='kern.exec.maxActorNumber' > 

51 < description > Maximum number of actors < /description > 

52 <int/> 

53 < const > 64 < /const > 

54 < /tunable > 
55 

56 < tunable name = 'kern. exec.maxThreadNumber' > 

57 < description > Maximum number of threads < /description > 

58 <int/> 

59 < const > 128 < /const > 

60 < /tunable > 



63 < /folder > 
64 

65 < /folder > 

66 

67 

68 < folder name= 'Memory managements 
69 

70 < folder name= 'Virtual Address Space' > 
71 

72 < condition > 

73 < var name = ' VIRTU AL_ADDRESS_SP ACE' / > 

74 < /condition > 
75 

76 < feature name = 'ON_DEMAND_PAGING' > 

77 < description > On-demand paging < /description > 

78 < condition > 

79 < and > 

80 <var name='VM_available' /> 

81 < var name ='PRM_available' /> 

82 </and> 

83 < /condition > 

84 <bool/> 

85 < false /> 

86 < /feature > 
87 

88 < /folder > 
89 

90 < /folder > 
91 

92 < /folder > 
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Claims 

1. A method of configuring software for a target, comprising: 

a. preparing commands (509) which specify: 

al. a subset of components selected from a group of 
components, 

a2. parameters (546) for tuning a least some of the 
selected components in said subset, and 

b. preparing an image file (540) fippm the command file, 
said image file constituting loadable software in a target, 

wherein step a. comprises writing said commands in a command 
file (509) using a single object-oriented programming 
language, capable of managing tree structures of objects. 

2. The method of claim 1, wherein said command file (509) 
is an XML file, and said single programming language is 
specified using an XML document type definition (201), 
having at least one nestable element predefined to 
receive an attribute pointing on a file. 

3. The method of claim 2, wherein said XML document type 
definition (201) has a predefined element adapted to 
form a condition, and has other elements adapted to 
receive a condition as an attribute, for conditionally 
processing such other elements. 

4. The method of claim 2, wherein said XML document type 
definition (201) has a predefined element adapted to 
form a constraint, and has other elements adapted to 
receive a constraint as an attribute, for conditionally 
accepting values of such other elements. 



5. 

35 



The method of claim 2, wherein said XML document type 
definition (201) has a predefined element adapted to 
launch an application with a parameter. 
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6. The method of claim 2, wherein said XML document type 
definition (201) has predefined feature and tunable 
elements for adapting the configuration. 

5 7. The method of claim 1, wherein the command file (509) 
and image file (548) are prepared on a host system 
separate from the target. 

8. A method according to claim 1, {/further comprising the 
10 step of : / 

c. loading (.5.5,0,.) the image file in the target. 

* 

9. A method according to claim 1, wherein step c) further 
comprises loading (550) the subset of components on the 

15 target. 



20 



10. The method of claim 1, wherein the image file (550) 
includes at least an operating system kernel and an 
operational file system. 

11. The method of claim 1, wherein the image file defines 
(550) parameters, actions, and memory layout of the 
software . 

25 12. The method of claim 1, wherein step b) comprises: 

bl. preparing a make file (535) from said command file, 



and 



b2. building said image file (548) using said make file. 



30 13. A computer program product, comprising the group of 
components of step al., the code of the XML document type 
definition (201) in claim 2, and the code for implementing 
step b. 

35 14. The computer program product of claim 13, further 
comprising code for implementing step a3. of claim 8. 



15. The computer program product of claim 13, further 
comprising code for implementing step c. of claim 9. 
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16. A system for configuring software for a target, compri- 
sing a host having 

a. A group of components; 

b. Software for preparing a command file (200,509) 
5 which specifies 

bl. a subset of components (545,546) selected from 

the group of components, 
b2. parameters (546) for tuning at least some of 

the selected subset of [components , 
10 b3 - loading (550) of the subset' of components on 

the target, 

said software using a single object-oriented 
programming language, capable of managing tree 
structures of objects, 

Software for preparing an image file (548). 



15 c. 



20 



17. The system of claim 16, wherein said command file 
(200,509) is an XML file, and said single programming 
language is specified using an XML document type defini- 
tion (201), having at least one nestable element prede- 
fined to receive an attribute pointing on a file. 



18 

25 



30 



The system of claim 17, wherein said XML document type 
definition (201) has a predefined element adapted to 
form a condition, and has other elements adapted to 
receive a condition as an attribute, for conditionally 
processing such other elements. 

19. The system of claim 17, wherein said XML document type 
definition (201) has a predefined element adapted to 
form a constraint, and has other elements adapted to 
receive a constraint as an attribute, for conditionally 
accepting values of such other elements. 



35 



The system of claim 17, wherein said XML document type 
definition (201) has a predefined element adapted to 
launch an application with a parameter. 
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21. The system of claim 17, wherein said XML document type 
definition (201) has predefined feature and tunable 
elements for adapting the configuration. 



22. The system of claim 16, further comprising: 

d. A link (900) for loading the image file and the 
selected subset of components in the target. 

l v 

10 23. A command file from which an image file for a target can 
be prepared, the^ command file specifying 7 

a. a subset of components (545,546) selected from a 
group of components, 

b. parameters (546) for tuning at least some of the 
15 selected subset of components, 

c. loading of the subset of components on the target. 

24. A computer program product comprising a computer-reada- 
ble medium, having a command file (200,509) from which 

20 an image file for a target can be prepared, the command 

file specifying 

a. a subset of components (545,54 6) selected from a 
group of components, 

b. parameters (546) for tuning at least some of the 
25 selected subset of components, 

c. loading of the subset of components on the target. 

25. The combination of the command file of claim 22 with the 
corresponding image file. 

30 

26. An XML processor, comprising: 

- a parser for acquiring at least a portion of an XML type 
file, and a corresponding document type definition (201), and 

- an analyser (211) for identifying objects in said portion 
35 of said XML type file, said objects comprising variables, 

values, operations, conditions and commands, 

whereby said XML type file may be used as a program 

file. 
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27. A Document Type Description for an XML type file, 
comprising a set of definitions of XML elements (201) 
comprising variables, values, operations, conditions and 
commands, 

whereby an XML type file may be used as a program file. 

28. The Document Type Description of claim 27, further 
comprising definitions of XML entities (201), usable in said 
definitions of XML elements. 
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